With the explosive growth in networked communications and ever increasing collaboration and mobile computing needs, today's enterprises struggle to determine the resources to which their various users have access. Today's enterprises struggle to determine what their users are doing with that access. A comprehensive awareness of access and enforcing governance controls helps to reduce the risk that an employee, contractor, or malicious third party with inappropriately assigned access will take advantage of that access. Sometimes, regulations exist that mandate access controls. To comply with such regulations, companies often need some way of providing meaningful evidence to auditors that explains how and why access was assigned within their environment.
For many enterprises, enforcing all such governance controls has been an ongoing challenge that is increasingly difficult to master. Business users are becoming more involved in driving the whole governance initiative. Business users more frequently request access to enterprise resources or delegate administration activities. Business users are more frequently involved in functions that were once considered to be the exclusive domain of the information technology department.
Enterprises seek a simplified and more business user-friendly experience that is easily customizable. In the past, enterprises were challenged by the lack of a unified governance suite offered by a single vendor. Provisioning, privileged access management, role management, and compliance products evolved independently of each other. This independent evolution led to customers implementing multiple products from multiple vendors as point solutions to address variant needs. As regulatory and provisioning requirements continue to grow and change, such multi-vendor solutions only increase the complexity and costs of managing and integrating these products. Enterprises end up relying heavily on each of these vendors for support. Enterprises end up committing significant resources to governance efforts for integration with little assurance that those efforts will prove successful.
A unified identity governance suite enables organizations to simplify access grants and audit access activities. Such a unified identity governance suite consolidates provisioning functions, privileged access functions, role management functions, policy management functions, and risk management functions. Through this consolidations, end-user productivity is increased, risk is reduced, operational efficiency is increase, and total cost is reduced. FIG. 1 is a block diagram that shows an example of some core components of a unified identity governance suite.
A unified identity governance suite can include an identity manager. Each user in an enterprise can have a separate identity. Such an identity manager can automate the administration of user access privileges across a company's resources, throughout the entire identity management life cycle—from initial on-boarding to final de-provisioning of an identity. An identity manager can help to provide information useful to comply with regulations. Such information might include an identification of the users that have access to each of an enterprise's resources. Such information might include an identification of the process through which each such user obtained access to each such resource. Such information might include an identification of the reasons that each such user has access to each such resource.
FIG. 2 is a block diagram that depicts an example of functions that can be performed by an identity manager. The identity manager's architecture can orchestrate complex information technology and business processes without requiring invasive changes to application infrastructure, policies, or procedures. The identity manager can distill core identity administration and provisioning functions into discrete layers. Changes to workflow, policy, data flow, or integration technology can be isolated within the respective functional layers, minimizing impact to applications. Configurations performed relative to the identity manager can be performed through a web interface. The identity manager may include an extensibility framework that allows the interface and its behavior to be tailored to the needs of each business.
An identity manger can offer a wide range of self-service functions that enable business users to register for an account and to manage their own profiles and credentials. An identity manager can provide a configurable interface through which end users can submit requests for accounts for themselves in the enterprise. A configurable workflow allows such requests to be approved before being granted. Users can be automatically notified regarding account details.
An identity manger can allow users to manage their own profile data. For example, an identity manager can allow users to change their e-mail identifier, postal address, telephone number, emergency contact information, password recovery questions and answers, etc. An identity manager can allow users to set up a proxy or delegate user to act on their behalf for a specified time period.
An identity manager can provide an interface through which each user can manage his own enterprise password, which he can use for single sign-on (SSO) purposes. The identity manager can synchronize this password across all target resources provisioned to the user in the enterprise. The identity manager can ensure that each password complies with enterprise password policies. The identity manager can be used to author such password policies. For the recovery of forgotten passwords, the identity manager can employ security challenge questions that were set during the user's first login or that were supplied when the user registered. The identity manager can provide random password generation capabilities that may be invoked during registration. The identity manager can enable administrators to reset user's passwords. The identity manager can randomly generate passwords to comply with password policies. The identity manager may send a randomly generated password to a user using various notification mechanisms such as e-mail, text message, etc. The identity manager can provide a password recovery mechanism that uses knowledge-based authentication or one time password-based challenge questions and responses.
Within an enterprise that includes an identity manager, each user can have a separate identity with its own state. This state can include a variety of attributes and corresponding values. The user's state can include attributes such as last login date and time, location from which last login occurred, last date and time of password change, quantity of incorrect login attempts, whether his account is currently active, locked, or suspended, etc. When a user exceeds an enterprise-wide specified maximum quantity of log-in attempts, that user's account can be at least temporarily locked out for some period of time, to prevent, for some period, further guesses by a possible hacker.
According to past approaches, all users within an enterprise were treated essentially in the same manner with regard to these lockout periods, regardless of who they were, their level of responsibility, their position in the organization, etc. Unfortunately, this one-size-fits-all type of lockout treatment can result in lockout periods being too lenient and insecure for users who have access to highly sensitive resources, and/or too restrictive for lower-level users who lack such access. Furthermore, such approaches did not consider the possibility that a user's position within an organization might change, potentially warranting different lockout handling as a result.
Additionally, account state information, including password state information (e.g., number of attempts at logging in, number of questions answered as part of password recovery process), has traditionally been stored in a variety of heterogeneous types of repositories coming from a variety of different vendors. Different repository types can represent account state information in different formats. In the past, client applications seeking to interact with each of these repositories had to do so by including different custom code for each different type of repository.
Furthermore, as is discussed above, an enterprise might need to be prepared to prove that it complies with certain regulations. This proof may be provided in the form of records created by an auditing subsystem. When a user submits a provisioning request—a request for access to some resource within the enterprise—it would be beneficial if a record of that request, and potentially its fulfillment also, could be generated and stored. Service Provisioning Markup Language (SPML) is the current language of choice for formatting provisioning requests. Clients typically make such requests through an SPML server that handles the requests. For security purposes, the SPML server performs authentication prior to handling an SPML request. However, for reasons of scalability (there might be thousands of users making such requests), an SPML administrator proxy account is typically the only account that authenticates with the SPML server. All users in the system then interact with the SPML server through this SPML administrator proxy account. The drawback of this approach is that an auditing system that seeks to record all of the activities performed by the SPML server does not truly know the identities of the users who initiated those activities; the SPML administrator proxy account is the only known account, which makes auditing information unreliable and less useful.